home *** CD-ROM | disk | FTP | other *** search
/ Sprite 1984 - 1993 / Sprite 1984 - 1993.iso / docs / howto / server-info / assault.debug.me < prev    next >
Encoding:
Text File  |  1992-12-14  |  4.8 KB  |  143 lines
  1. .uh "How to Boot Assault"
  2. .pp
  3. I am ``Assault'', A Sprite file server.  To boot after a power-up:
  4. .(l
  5. >>init
  6. \fI there will be a pause, then some info printed out\fP
  7. >>boot -f rz()new
  8. \fI a number should appear immediately, which is the size of the text being loaded\fP
  9. .)l
  10. The above commands will cause Assault to boot off of its disk.
  11. If Assault doesn't boot, then make sure you typed 'init' before 'boot'.
  12. If it still doesn't work then try booting off of Allspice:
  13. .(l
  14. >>init
  15. \fI there will be a pause, then some info printed out\fP
  16. >>boot -f tftp()new
  17. \fI a number should appear immediately, which is the size of the text being loaded\fP
  18. .)l
  19. If Assault still won't boot,
  20. then go to Allspice and ensure that its 'bootp' daemon
  21. is running, as well as its 'rarp' and 'arp' daemons.
  22. .pp
  23. To reboot when running Sprite, use the shutdown command:
  24. .(l
  25. % sync
  26. % shutdown -h
  27. .)l
  28. The 'sync' command writes out the cache, is isn't required unless
  29. you are parnoid.  Shutdown will sync the disks as the last thing before
  30. rebooting.
  31. After Assault halts, reboot it as described above.
  32. There is no autoboot for the descstations, apparently.
  33. .pp
  34. If Assault is so wedged you can't do anything from its console,
  35. then attempt to sync the cache with:
  36. .(l
  37. F1-W
  38. .)l
  39. You should get a message about syncing the disks.
  40. You can abort to the PROM with
  41. .(l
  42. F1-A
  43. .)l
  44. Or, as a last resort, you can reset it with the reset button
  45. on the back.
  46.  
  47. .uh "Debugging Tips"
  48. .pp
  49. If Assault acts up then you might try the following things.
  50. If you aren't logged in, log in as root.
  51. Useful commands are:
  52. .(l
  53. assault # rpcstat -srvr
  54. .)l
  55. Which dumps out the status of all the RPC server processes.  If a bunch
  56. are ``busy'', and they remain busy with the same RPC ID and client, then
  57. there may be a deadlock.
  58. If they are all in the ``wait'' state it means that the Rpc_Daemon process
  59. is not doing rebinding for some reason.
  60. .(l
  61. assault # ps -a
  62. .)l
  63. This will tell you if any important daemons have died.
  64. If the ipServer is in the DEBUG state you can kill it and
  65. the daemons that depend on it with /hosts/assault/fixIPServer.
  66. This should also restart these daemons, but if it doesn't you
  67. can use /hosts/mint/restartservers.
  68. .(l
  69. % rpcecho -h \fIhostname\fP -n 1000
  70. .)l
  71. This program, which is found in /sprite/src/benchmarks/rpcecho,
  72. and may or may not be installed in /sprite/cmds,
  73. will tell you if there timeouts when using the RPC protocol to
  74. talk to another host.  If you suspect that a host with an Intel
  75. ethernet interface is flaking out, you can try this command.
  76. Lot's of timeouts indicate trouble.
  77. You can reset a host's network interface from its console with
  78. either of these keystrokes.
  79. .(l
  80. Fl-N
  81. break-N
  82. Ll-N
  83. .)l
  84. On a regular DecStation keyboard you use the F1 key like a shift key.
  85. On a regular Sun keyboard you use the L1 key like a shift key.
  86. On an ascii terminal you use the break key like an escape key,
  87. hit break, then the key.
  88.  
  89. .uh "Kernel Debugging"
  90. .pp
  91. If Assault is so hung you can't explore with user commands,
  92. then the best you can do is sync the disks with:
  93. .(l
  94. F1-W
  95. .)l
  96. This should print a message about queuing a call to sync the disks,
  97. and when it is done it should print a '.' and a newline.
  98. If you don't get the newline then Assault is deadlocked inside the
  99. file system cache, sigh.  Throw Assault into the debugger with:
  100. .(l
  101. F1-D
  102. .)l
  103. You should get
  104. a message about ``Entering the debugger...''.
  105. (If not, I think you're forced to reboot.)
  106. .pp
  107. You have to run the debugger from dill, which is behind you.
  108. The kernel images should be copied to dill:/sprite/src/kernel/nelson,
  109. and their version number should be
  110. evident in their name, i.e. ds3100.1.043.  If not, you can run
  111. strings on the kernel images and grep for ``VERSION''.
  112. .(l
  113. dill% strings /sprite/src/kernel/nelson/ds3100 | egrep VERSION
  114. .)l
  115. To run the kernel debugger (a variant of dbx)
  116. .(l
  117. dill% cd /sprite/src/kernel/nelson
  118. dill% Kdbx ds3100.\fIversion\fP assault
  119. .)l
  120. If there is a deadlock you can dump the process table:
  121. .(l
  122. (kdbx) set $pdump = 0
  123. .)l
  124. You can switch from process to process and to stack backtraces
  125. by using the 'set $index = pid' command.  You only need to specify the last
  126. two hex digits of the process ID.  If you only have a decimal ID,
  127. then you have to type the whole thing.
  128. File system deadlocks center around locked handles, usually.
  129. When you find a process stuck in Fsutil_HandleFetch of Fsutil_HandleLock
  130. you can try to find the culprit by looking at the *hdrPtr these
  131. guys are waiting on.  There is a 'lockProcessID' in the hdrPtr that
  132. is really the address of a Proc_ControlBlock.  You can print this out
  133. with something like:
  134. .(l
  135. (kdbx) print *(Proc_ControlBlock *)(hdrPtr->lockProcessID)
  136. .)l
  137. You cannot reboot Assault from within kdbx.  You have to abort it,
  138. or reset it with the reset button on the back of the machine,
  139. and then reboot it as described above.
  140. .uh "Modify date"
  141. .pp
  142. These notes were last updated by Brent Welch on \*(td.
  143.